A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage (NAS) environment, a storage area network (SAN), and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on volumes as a hierarchical structure of data containers, such as files and logical units. For example, each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are organized within a volume block number (vbn) space that is maintained by the file system. The file system may also assign each data block in the file a corresponding “file offset” or file block number (fbn). The file system typically assigns sequences of fbns on a per-file basis, whereas vbns are assigned over a larger volume address space. The file system organizes the data blocks within the vbn space as a “logical volume”; each logical volume may be, although is not necessarily, associated with its own file system.
A known type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and “dirtied” (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL™) file system available from Network Appliance, Inc., Sunnyvale, Calif.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access data containers, such as files and logical units, stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the storage system by issuing file-based and block-based protocol messages (in the form of packets) to the system over the network.
In order to improve reliability and facilitate disaster recovery in the event of a failure of a storage system, its associated disks, or some portion of the storage infrastructure, it is common to “mirror” or replicate a data set comprising some or all of the underlying data and/or the file system that organizes the data. A data set comprises an area of defined storage which may have a mirroring relationship associated therewith. Examples of data sets include, e.g., a file system, a volume, or a persistent consistency point image (PCPI), described further below.
In one example, a mirror of a file system is established and stored at a destination, making it more likely that recovery is possible in the event of a true disaster that may physically damage a source storage location or its infrastructure (e.g. a flood, power outage, act of war, etc.). The mirror is updated at regular intervals, typically set by an administrator, in an effort to maintain the most recent changes to the file system on the destination. The storage systems attempt to ensure that the mirror is consistent, that is that the mirror contains identical data to that of the source.
In addition to being used for improved reliability and to facilitate disaster recovery, mirrors may also be used for load balancing data access requests. In particular, a distributed storage system environment may provide access to a data set (e.g., a volume) for a large number of clients. As such, the large number of corresponding access requests for that data set may become a bottleneck, where generally one particular storage system maintaining the data set services each of the requests. For instance, where a root volume is stored at the particular storage system, each access request to the root volume is serviced by that storage system (as will be understood by those skilled in the art). To pre-vent that storage system from becoming a bottleneck, one technique is to provide read-only load-balancing mirrors of the data set stored on one or more of the storage systems of the distributed storage system environment. In particular, a data set that is accessed often, yet that is not modified often (e.g., the root volume), is a good candidate for mirroring. In this manner, any read-only access request from a client for the mirrored data set (e.g., the root volume) may be serviced from any storage system having a mirrored copy, thus alleviating the bottleneck at the storage system maintaining the original version of the mirrored data set (the “master” data set or volume).
By creating multiple read-only “replicas” of a data set and/or volume across distributed storage systems, a mirrored storage environment may advantageously provide read-only load-balancing. However, one problem associated with mirrored storage environments is how to easily provide access to the writeable master storage volume for any client to update the data, yet still have the benefits of load-balanced read access from the read-only mirrored storage volumes. There remains a need, therefore, for an efficient and straightforward technique for specifically accessing a writeable master storage volume in a mirrored storage environment, particularly for both read and write access requests.